fix(runtime): propagate share scopes to nested remotes - #4913

Description

Propagate the complete host share scope map when initializing a remote container.

Previously, only the share scope selected for the current remote was added to the remote container's runtime state. When that remote loaded another nested remote using a different share scope, the nested remote could not access shared dependencies from the upstream host. This could cause singleton dependencies such as React to be loaded more than once.

This change:

• Copies the inherited host share scope map into the remote container while preserving the explicitly initialized scope.
• Allows nested remotes to reuse shared dependencies already provided by the upstream host.
• Adds a regression test covering the Host A → Remote B → Remote C initialization path with separate React 18 and React 19 share scopes.
• Adds a patch changeset for @module-federation/runtime-core.

Validation

• pnpm --filter @module-federation/runtime-core test -- instance.spec.ts
  • Passed all 93 tests across 12 runtime-core test files.
• pnpm --filter @module-federation/runtime-core lint
  • Passed.
• pnpm --filter @module-federation/runtime-core build
  • Passed.
• pnpm exec prettier --check packages/runtime-core/__tests__/instance.spec.ts packages/runtime-core/src/shared/index.ts .changeset/fix-nested-remote-share-scopes.md
  • Passed.
• Confirmed that the regression test fails when the share scope map propagation is removed and passes with the fix applied.
• Manually verified the original reproduction: the nested React component renders successfully without loading a duplicate React instance.

Related Issue

Fixes #4723

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Checklist

• I have added tests to cover my changes.
• All new and existing tests passed.
• I have updated the documentation.